第9章 イテレーションの運用：実現させる

9.1 価値ある成果を毎週届ける

1. 要求をドキュメント化するときには、必要な分だけにし絞ること

2. 実装開始直後から動く状態にしておく。設計やテストを常に行うことこ

3. テストは後に回さずテストの開発と同時に行うこと

9.2 アジャイルなイテレーション

イテレーションとはサイクル期間を固定した単位

基本は1週間か2週間

9.3 急募・アジャイルチーム・切実

ここからは実際のプロジェクトを例に解説する。

とある建設プロジェクトの開始日が1ヶ月早まりストーリーを担当してくれと言われた

作業許可証を申請する：5pts

作業許可証を印刷する：3pts

このストーリーを実現するためには、以下の3ステップをこなしておく

1. 分析して設計する（作業の段取りをする）

2. 開発する（実際に作業する）

3. テストする（作業の結果を確認する）

9.4 ステップ1: 分析と設計：作業の段取りを行う

必要な分だけを必要なときに分析する

同じ作業場に顧客がいるならば、インデックスカードと会話とちょっとした図・イラストがあるだけでいい

規模が多くなって複雑であれば、概要をまとめた1ページぐらいのテキストにまとめること

ストーリー名：作業許可証

説明

委託業者が工事現場で作業するにあたって、法令尊手のための危険作業許可証が必要が。この許可書は、着手できるようになったら現場に持参する

タスク

1. 許可証を申請する画面を作る

2. 許可証をデータベースに保存する

3. 入力値の簡単な妥当性検査を行う

4. セキュリティは考えない(このストーリでは)

テスト条件

1. 申請書は許可証を保存できること

2. 許可証はデータベースに保存されていること

3.許可証の入力値に不備ばあれば却下されること

4. 許可証の開始日付はデフォルトでは翌週が開始日付になっていること

「ここまでやればいい」という判断基準はない。そのプロジェクトで適切に分析されているかの判断をする。

必要な分だけ、必要なときに掘り下げて分析する

ジャストイン分析を行う

ジャストイン分析は次のイテレーションで実施するストーリを分析すること

以下の効果がある

最新かつ最も充実した情報に基づいて分析できる

君も顧客も学ぶ機会を増やせるので、プロジェクトが進めにつれて分析がうまくなってくる

手戻りが大量に発生することを避けられる

ストーリーが非常に複雑な場合でも、作業ができるまで時間をかけて分析をするしかない

フローチャートを作ってシステムの流れを可視化する

ペルソナを作って、役割ごとのフィーチャーの概要を記載すうる

受け入れテストを書いて、ストーリーの満足を条件を定義する

最初は概要でもいい。徐々に顧客と会話して詳細に条件を追記していく

チーム全体が把握できたと思えるレベルまで質問を続けること

9.5 ステップ2: 開発：作業する

こまかい開発工程は今後の章で解説する

まだプルジェクト開始時に、まだ開発者の環境が整っていない場合は、開発の段取り（イテレーション・ゼロ）を済ませておく

9.6 ステップ3: テスト：作業の結果を確認する

かならず顧客に受け入れテストをしてもらってフィードバックをえること。

可能であればテスト中の画面を見てもらってどうやって操作しているのかを知るといい

顧客のテストを軽視する傾向がある。本気にテストしてもらえるのは、最終的な受け入れテストの時が多い。なので、かならず受け入れテストは実施すること

9.7 カンバン

カンバンの名前はトヨタが開発した情報伝達システムに由来

WIPという概念があり、チームで作業できるストーリー数を確認できる値がある。たとえば、WIPが3の場合、チームが同時に作業できる内容は3までということになる

作業ができないタスクには優先順位を決めて、作業が終わった人は優先度のたかいタスクを担当する

このカンバンはイテレーションは関係なく運用できる。期限と予算が決まっている開発には、イテレーションを使用するといいが、突発的な作業（運用など）が発生し、優先して対応していいプロジェクトであればカンバンを使用することもあり